home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20000217-20000824
/
000220_news@columbia.edu _Mon Apr 24 12:36:36 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2000-08-23
|
6KB
Return-Path: <news@columbia.edu>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
by monire.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA26274
for <kermit.misc@cpunix.cc.columbia.edu>; Mon, 24 Apr 2000 12:36:35 -0400 (EDT)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id MAA25376
for <kermit.misc@watsun.cc.columbia.edu>; Mon, 24 Apr 2000 12:36:35 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id MAA18621
for kermit.misc@watsun.cc.columbia.edu; Mon, 24 Apr 2000 12:15:36 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: fdc@columbia.edu (Frank da Cruz)
Subject: Re: Parity incorrectly reported, and RTS/CTS problem on Solaris 7 for x86
Date: 24 Apr 2000 16:15:35 GMT
Organization: Columbia University
Message-ID: <8e1rv7$i5p$1@newsmaster.cc.columbia.edu>
To: kermit.misc@columbia.edu
In article <3904650F.A10717AF@yk.rim.or.jp>,
Ishikawa <ishikawa@yk.rim.or.jp> wrote (of C-Kermit 7.0):
: First, thank you for the great package. I asked a few questions
: concerning the usage of 8 bits byte, and an even parity several weeks ago
: on linux and after the kind answers I could get kermit going on Debian
: GNU/linux well.
:
Good...
: [1] One cosmetic bug.
:
: I set the parity to "parity hardware even" (8E1). But the parity shown
: on the receiving server side (i.e., after I type "server" [CR]) is `none'
: instead of `hardware even'. Maybe this discrepancy can be fixed.
: ...
: But, the CRT display on the server side is as below.
:
: --- begin quote
: C-Kermit 7.0.197, 8 Feb 2000, www [192.9.200.253]
:
: Current Directory: /tmp
: Communication Device: /dev/ttya
: Communication Speed: 115200
: Parity: none <---- buggy?
: RTT/Timeout:
: ...omitted ...
: --- end quote
:
This is not actually a bug. As far as Kermit protocol is concerned, the
parity really is "none". This means it is using all 8 bits of each byte for
data, and it doesn't have to use single shifts or locking shifts to encode
bytes whose 8th data bit is 1. But yes, I agree it might be clearer to list
something like "none (8E1)" here. I'll add it to my list.
: Now a little complicated one.
: I am not sure if this is a bug or feature.
:
: [2] A user expectancy problem. RTS/CTS is not supported by
: pre-compiled binary for Solaris 7 for x86.
:
: But kermit doesn't complain if I specify rts/cts flow-control, and
: SILENTLY ignored my request, so to speak.
:
Thanks for the report. We don't have hands-on access to Solaris x86 (any
version) here, so never noticed this one. All our Solaris x86 binaries were
built at remote sites, where we couldn't experiment with modems, or sent in
by others. (Note: we still don't have a Solaris 2.6 x86 binary.)
: *USER EXPECTANCY PROBLEM*: C-kermit doesn't complain at all when I typed
:
: set flow-control rts/cts
:
: and doesn't say a thing when I typed
:
: connect
:
C-Kermit 7.0 for Solaris is built with -DCK_RTSCTS, which tells it to
include the commands for setting, showing, and using RTS/CTS. This has been
true ever since Solaris 2.0. It happens automatically in ckcdeb.h, because
STERMIOX is defined, which in turn means that <system/termiox.h> is available,
which defines the System-V based hardware flow-control API.
: It simply failed to set RTS/CTS and merrily goes on processing. Beat me why
: it did NOT give me any warning about not-supported RTS/CTS or maybe the code
: forgot to handle the non-supported case since the code to handle CRTSCTS is
: cluttered with many #ifdef's.)
:
That's what makes it work on hundreds of different platforms :-)
The reason you didn't get a warning is that C-Kermit is indeed calling the
<system/termiox.h> APIs for setting RTS/CTS, and the APIs are not returning
an error. (Take a debug log and search for "tthflow".)
: Anyway, after I modified the supplied `makefile' to define
: POSIX_CRTSCTS (and inserted a few fprintf(stderr,"...") lines just to
: let me make sure the expected lines to enable RTS/CTS flow control are
: executed) and recompiled the C-kermit-7 code, I verified that now that
: the RTS/CTS enable code is executed and the transfer at 115200 bps
: (8E1) with flow-control of rts/cts works and transfer of wermit binary
: (about 1.6MB) using packet length of 3999 (default) with D-type packet
: went well(!).
:
Good! So it seems that the System-V RTS/CTS APIs have stopped working in
Solaris 8 and a non-backwards-compatible switch as been made to the POSIX
APIs. This is a "double ended error": the old API is broken, but it doesn't
inform the application of any problem.
: I have no idea at this moment if solaris 7 for sparc (not x86) should work
: with this modification, but it should. If not, maybe we need a different
: target (solars7x86 against solaris7) just in case. YMMV.
:
This, of course, is an important question. What is the earliest version of
Solaris that has the POSIX API for RTS/CTS available (and working!)? What
is the latest version of Solaris that has the System V API working? Is there
a difference between x86 and Sparc versions?
: Here is the patch to makefile (for solaris 7 for x86).
: I simply inserted -DPOSIX_CRTSCTS.
: (Is this macro supposed to be automatically defined when one says
: -DPOSIX? From the comment I found in the code, I don't think so, but
: just have to ask.)
:
No, it is not, and should not be. You can never assume anything like this.
To C-Kermit, -DPOSIX means POSIX 1.0, which has nothing whatsoever to say
about hardware flow control; POSIX OS's implement hardware flow control in
all sorts of creative and incompatible ways.
I'm cross-posting this reply to the Solaris lists in case anybody there can
answer the questions above. Unfortunately, however, the only real test is
to build C-Kermit both with and without -DPOSIX_CRTSCTS on every Solaris
platform and test the flow control.
- Frank